The present invention relates generally to integrated circuit (IC) design and debugging. More particularly, the present invention relates to apparatus and methods for developing, testing and/or debugging prototype systems to be implemented on a single IC die.
As transistor size continues to decrease, massively complex systems are being implemented on a single die. This results in a “system-on-a-chip” that is exceedingly difficult to debug. In the current environment, systems-on-chips are moving toward multiple system busses, each of 64-bits in width. These busses all operate independently and may have multiple masters and slaves. Each may also connect to common shared slaves, or may communicate via bus bridges. These systems may also contain multiple microprocessors, memory controllers and other peripherals.
Debugging such systems is equivalent to debugging the printed circuit board (PCB) type systems of ten years ago. However, in the case of PCB-type systems, debugging was comparatively easy since all signals were essentially visible or accessible outside of a packaged die at the PCB level as test points, or at the PCB-to-backplane connection via the connectors. Debugging a system-on-a-chip is much more difficult.
With the high level of integration which is possible in semiconductor processes, the mask costs are rising exponentially. With the high mask costs, it is very expensive to build the prototype system in silicon. With each mask redesign and subsequent fabrication in silicon, the system development costs rise by as much as one million dollars. Therefore, it is prohibitively expensive to design and debug a system by repeatedly redesigning the mask and repeatedly fabricating corresponding prototypes in silicon.
Another problem encountered in system-on-a-chip design relates to the development time required to design the system. Frequently, software developers must wait for hardware designers to complete a prototype chip. Once the hardware is available, the software developers write and test code for it. If the software developers discover a problem in the hardware design, it is frequently necessary to go back and revise the hardware design, creating a new mask, and fabricating a new chip. In addition to being expensive, this serialized and potentially iterative process is very time consuming. With the rapid change in technology, a lengthy development process is often unacceptable.
Current solutions to these problems include: (1) hardware/software co-simulation; (2) use of field programmable gate array (FPGA) prototype systems; (3) emulation of designs in large electronic arrays that map designs into FPGAs and simulate function; and (4) building huge PCBs to capture the complete system design. The first approach, hardware/software co-simulation, is lacking because current solutions of this type rely on specific software vendors to have all components modeled correctly for simulation acceleration. When they are not modeled correctly, the tool simulates extremely slowly. In real-time applications in which the only true test that the software under development is working correctly is to run a real-time data stream, this solution and performance is unacceptable, particularly as complexity increases.
The second current approach to resolving the above-identified problems, use of FPGA prototype systems, is lacking primarily for the same reasons as the first approach. These systems are not capable of processing the real-time data streams which will exist on a system-on-a-chip. In addition, the complexity of the platform always leads to a lesser-implemented system and design tradeoffs. It is not sufficient to validate a design in this manner since the design that is being validated is different from the one that will be implemented in silicon. The software and system-level engineers, as well as the VLSI engineers, require that the real system be prototyped.
The third approach to resolving these problems, emulation of designs in large electronic arrays that map designs into FPGAs and simulate function, is lacking since the systems do not operate quickly and are often architected to handle the platform-based approach. Again, the same real-time operation is in question, as is the capacity of this solution. These electronic arrays are typically not large enough to handle the systems currently being built. The fourth approach, building a huge printed circuit board to capture the complete system design, is lacking primarily because it is not reusable. Any such printed circuit board would be specific to each platform-based system. The costs would be very high, and the debug and validation of the system cannot be leveraged into other projects.
Therefore, a solution to these design and debugging IC development issues, which has relatively low costs per project and which does not excessively delay the development process, would be a significant improvement in the art.